1. Field of the Invention
The invention relates to a mobile radio communication device, and a method of managing connectivity status for the same.
2. Description of the Related Art
The increased functionality offered by a mobile radio communication device such as a cellular phone handset has arisen from technical developments relating to the various circuit elements of the cellular phone handset, the operating and application software and also from improvements relating to network operation and characteristics.
One recent development has focused on the Subscriber Identification Module (SIM) card employed within a mobile phone handset and, in particular, relates to the adoption of internet-related technology within a SIM card device.
One such development relates to the provision of a web server running in a subscriber identification module card, which allows for the provision of SIM-based services whilst taking advantage of the multimedia capability already present in the mobile phone handset and relating, for example, to data display and/or information processing.
That is, the provision of such a smartcard web server allows for internet-related design characteristics to be incorporated into SIM card applications, and this can lead to advantages such as enhanced and unified graphical user interface (GUI) for SIM-based services, the storage of static pages such as a browser's homepage, and also the use of dynamic web pages.
Such pages can prove attractive to network operators as a means for increasing on-line revenue.
Further, control of a SIM-based services menu can readily be profiled so as to match the end-user's preferences and common requirements.
Connectivity with the mobile phone handset to the smartcard web server is achieved by way of a Bearer Independent Protocol (BIP) channel, and so use of such a BIP server allows support within the mobile phone handset of the local smartcard web server which is then readily accessible by the handset browser.
However, limitations are nevertheless experienced concerning the manner in which channel status signals are developed and employed within the mobile phone handset particularly with regard to connectivity to the smartcard web server and to a related transport connection protocol (TCP) client/server pair.
As discussed further below with regard to limitations found in the related art, it is found that the mobile phone handset can disadvantageously lose local connection within the TCP client/server pair within the mobile phone handset, and then, the browser associated with the smartcard web server will then make an attempt at reconnection. The data exchanges that arise in relation to such reconnection will lead to a decrease in the speed of operational processing within the mobile phone handset.
Further, it can disadvantageously be found that limitations arise with regard to the manner in which indications can be provided to the smartcard we server device that the server of the TCP client/server pair is ready for re-connection and, in order to ensure successful further connection, the smartcard web server will server to close, and then, re-open the channel. Such attempted re-connection, and associated closing and re-opening of the channel will likewise lead to an increase in message being generated, and this is found to have a disadvantageous effect of slowing down the data exchange in the mobile phone handset.
In general, current systems are disadvantageously limited since, for client mode operation, there is generally only provided an arrangement for indicating the status of the bearer connection by means of “line dropped with packet connection activated” status signals or “line dropped with packet connection deactivated” status signals.
FIGS. 1, 2 and 3 are timing charts showing channel status found in the related mobile radio communication device.
Hereinbelow is explained the problem found in the related mobile radio communication device, with reference to FIGS. 1 to 3.
FIG. 1 is a timing chart illustrating channel status events with regard to status transmissions within a mobile radio communication device handset and between a network connection 10, a browser 12, a TCP/IP client 14, a TCP/IP server 16, USAT 18, USIMM 20, and a web server circuit card 22 in the form of a Universal Mobile Telecommunications System Integrated Circuit Card (UICC).
As noted above, in accordance with current IP specifications for operation in client mode, there is only one manner in which status of the bearer connection is provided by way of “line dropped with packet connection activated” and “line dropped with packet connection deactivated” status signals.
As illustrated in FIG. 1, with a normal service signal 24 originating from the network 10, channel status signals 26 are provided from SAT 18 and USIMM 20, confirming packet connection activated and link established.
Then, the mobile radio communication device is in a mode waiting for receipt of a new network status, as indicated by an arrow 28.
When a new network status, for example “no service” is received from the network, as indicated by an arrow 30, the channel status 32 to the circuit card 22 is changed as indicated to packet connection activated and line dropped.
It should however be appreciated that, the “no service” signal can arise through the mobile phone handset being out-zone temporarily, but with its packet connection context, not deactivated by the network 10. This leads to the “line dropped with packet connection activated” or “line dropped” status signal 32.
The mobile radio communication device is then again waiting for a new network status such as indicated by an arrow 34.
On receipt of a new network status, such as “service detached” as indicated by an arrow 36 from the network 10, the packet connection context is then deactivated by the network 10, and the data link is downed. This leads to the channel status signal 38 indicating “packet connection deactivated” or “line not established”.
It should be however be appreciated that the above-mentioned channel status signals are used primarily in order to indicate the network status, i.e., the incoming signals arising from the network source 10, and are not employed for describing the TCP client/server pair status connection.
The TCP client/server pair status connection can comprise various status such as “listening”, “listening and connected”, “listening and disconnected”, and, again “listening”.
When listening, the TCP/IP server 16 is waiting for connection from a remote client, and the status “listening and connected” arises when connection from a remote client to the TCP/IP server 16 is achieved for subsequent data exchange.
Once the remote client disconnects this connection to the TCP/IP server 16, the shutdown status is sent to the TCP/IP server 16, leading to the “listening and disconnected” status.
As noted above, various limitations and related problems can arise from the above-mentioned channel status management.
For example, with regard to the bearer connection channel status signals currently arising, i.e. “link established or packet connection activated” or “link not established or packet connection not activated”, the subscriber identification module card (smartcard) web server is enable to determine if a client is connected or not, as indicated by the “link established” and “link not established” status signals.
Furthermore, in this scenario, it will not be possible for the subscriber identification module card (smartcard) web server to determine the difference between a client connection status signal and a network change status signal.
Thus, if the network 10 sends a change status signal to the mobile radio communication device, a revised channel status signal will be sent to the web server circuit card 22.
For example, if a “SERVICE_DETACHED” status signal is received from the network 10, the mobile radio communication device then will send a “link not established” signal as indicated in FIG. 1 such that the web server circuit card 22 will then proceed to send a close channel status signal. This close channel status signal will serve to reset the local connection with the client.
Such operation proves particularly disadvantageous in that the user will then lose its local connection temporarily, and the browser 12 will attempt a re-connection and the data exchanges arising in relation to such attempted re-connection. This will lead to a decrease in possible speed for the data exchanges within the mobile radio communication device.
Such problematic operation within the current state of the art is illustrated with reference to FIG. 2.
FIG. 2 is a timing diagram showing status signals arising within a network connected mobile radio communication device, and illustrating the network connection 40, the browser 42, the TCP/IP client 44, the TCP/IP server 46, the BIP/SATS 48, and the web server circuit card 50.
The channel status indicated by the web server circuit card 50 is initially an OPEN_CHANNEL status indicated by an arrow 52, which arises with an automatic re-connection flag off.
To initiate activity, the browser 42 sends a first request as indicated by an arrow 54, but, prior to this, the BIP channel status is indicated by an arrow 56 as “link not established”.
This TCP connection status as sent to the web server circuit card 50 then changes to “link established” as indicated by an arrow 58 upon connection 60 being achieved between the TCP/IP client 44 and the TCP/IP server 46.
The browser 42 and the web server client card 50 are then able to exchange data, as indicated at block 62, prior to receipt of a “service detached” status signal 64 received from the network 40. In this scenario, the network 40 releases the packet connection during data exchanges between the web server circuit card 50 and the browser 42.
A CLOSE_CHANNEL status signal 66 is then generated and issued by the web server circuit card 50 in response to the web server circuit card 50 receiving a “link not established” status signal on its BIP channel.
Disconnection 68 between the TCP/IP client 44 and the TCP/IP sever 46 then arises such that the close channel status signal 66 transmitted from the web server circuit card 50 leads to the browser 42 losing connection to the web server circuit card 50.
Subsequent to the disconnection 68 between the TCP/IP client 44 and the TCP/IP server 46, the channel status signal delivered to the web server circuit card 50 remains as “link not established”.
As noted above, such loss of connection and attempted re-connection in the browser 42 leads to a disadvantageous decrease in the rate of data exchanges within the mobile radio communication device.
FIG. 3 is a timing diagram illustrating channel status signals arising within a mobile radio communication device according to the current art, and illustrating standard TCP connection with channel status events arising without network interaction.
FIG. 3 illustrates in particular a further problem arising in the current art in that there is no manner for indicating to the web server circuit card 50 that the TCP/IP server is ready to receive a further connection consistent with the previous connection.
Accordingly, in order to ensure operational connectivity, the web server circuit card 50 has to operate to close, and then, re-open the BIP channel in spite of presence of the automatic re-connection flag.
In view of such operation, the number of messages arising within the mobile radio communication device channel will increase and serve to slow down the general data change within the mobile radio communication device such that normal service from the mobile radio communication device will be unavailable temporarily, i.e. during the close/open phase of operation initiated by the web server smart card.
FIG. 3 illustrates the network 40, the browser 42, the TCP/IP client 44, the TCP/IP server 46, a BIP/SA 48, and the web server circuit card 50.
An OPEN_CHANNEL status signal 52 is provided from the web server circuit card 50, arising with the automatic re-connection flag set.
In this scenario illustrated in FIG. 3, no status signals are transmitted from the network connector 40, and the process proceeds to the browser 42 sending a first request, as indicated by an arrow 54.
Prior to sending such a first request, a channel status signal “link not established” is sent from the TCP/IP server 46 to the web server circuit card 50, as illustrated by an arrow 56.
An event is changed to the channel status to “link established”, as indicated by an arrow 58, and subsequent to connection 60 is established between the TCP/IP client 44 and the TCP/IP server 46.
The subsequent to the connection 60 and at the time of establishing the channel status 58, the TCP connection status signal is sent to the web server circuit card 50, but there is no information concerning the server status, in particular, whether the TCP/IP server 46 might be considered to be listening on the channel.
Subsequent to the link being established, the browser 42 and the web server circuit card 50 exchange data as required, as indicated by block 62.
As will be appreciated, the channel status and connection modes discussed above in relation to FIG. 3 are consistent with those arising initially in relation to FIG. 2.
However, in FIG. 3, subsequent to the exchange of data between the browser 42 and the web server circuit card 50, a connection cut is experienced between the TCP/IP client 44 and the TCP/IP server 46, as indicated by an arrow 72, and this leads to a change in channel status to “link not established”, as indicated by an arrow 74.
A signal indicative of the connection cut 72 may be sent while a receiver buffer is empty and not during or before a transmission so as to simplify the web server circuit card 50.
Assuming the second request 76 leads to a successful connection, as indicated by an arrow 78, the TCP/IP server 46 initiates the change in connection status to the web server circuit card 50 such that the channel status to the web server circuit card 50 is changed to “link established”, as indicated by an arrow 80.
With the link now established, the browser 42 and the web server circuit card 50 initiate a new data exchange, as indicated by block 82.
The closing of the channel status 74, the subsequent second request 76 sent by the browser 42, the attempted further connection 78, and status change 80 will result in a large number of messages which grow to disadvantageously slow down data exchange between the browser 42 and the web server circuit card 50.